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[57] ABSTRACT 

A telecommunications system infrastructure that facilitates 
easy insertion of feature software into existing such tele- 
communications systems and easy integration of the new 
calling features and their implementing software with exist- 
ing features and their software. The infrastructure comprises 
the Lucent Technologies MMCX multimedia communica- 
tions server (100) and middleware-compliant communica- 
tions endpoints (101-102) executing the Lucent Technolo- 
gies MMCX communications middleware (111-112). 
Feature-implementing software has a modular client/server 
construction, with feature managers (server modules. 300, 
350) executing on the MMCX server and feature adminis- 
tration agents (client modules, 303-353, 304-354) execut- 
ing on the endpoints. The infrastructure provides a context 
service (120) and a context API (121) for registering an 
instance of a feature manager (a user policy, 301-302, 
351-352) for each user upon that user becoming entitled to 
the feature, an administration API (360) for communications 
between feature managers and feature administration agents 
on the user's endpoint to customize the user's user policies 
for the user, and a context (a cyberspace meeting room, 200) 
and the context API for involving the user policies of users 
who are parties to a call in the call and for communicating 
call-related events to feature servers and other service- 
implementing software. Call-related events are passed to 
user policies involved in the call, and they are given a chance 
to react to the events by allowing or rejecting the events. 
Interactions between features are managed by having feature 
managers register at different priorities with the context 
service; higher-priority modules are serially given an oppor- 
tunity to allow or reject events before lower-priority mod- 
ules. 

10 Claims, 5 Drawing Sheets 
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ARRANGEMENT FOR FACILITATING 
PLUG-AND-PLAY CALL FEATURES 

TECHNICAL FIELD 

This invention relates to stored-program-controlled com- 
munications systems, including multimedia communica- 
tions systems. 

BACKGROUND OF THE INVENTION 

Traditionally, adding calling features to switching-system 
(e.g., central office or PBX) control software has required 
modifying existing feature programs while paying careful 
attention to interactions between existing features and the 
new features. For example, implementing call-center fea- 
tures on a PBX that already provides call-forwarding and 
call-coverage requires careful coordination between the two 
sets of features, ensuring that calls are handled correctly 
when a call-center agent enables call-forwarding or call- 
coverage. In a multimedia telecommunicaions system where 
users are presented with graphical user interfaces, the need 
to provide new user interfaces to control new features poses 
an additional problem: in order for the endpoint user- 
interface and the server feature- software to communicate, 
the endpoint-to-server protocol generally needs to be 
updated. 

The above-mentioned constraints present an imposing 
barrier to developers who are responsible for continuing 
maintenance and upgrades of the features. These constraints 
present an even-more imposing barrier to the development 
by third-party vendors of new features or of new versions of 
existing features. Third parties generally have neither the 
interest nor the capability to modify the telecommunications 
system software in order to make their feature software fully 
compatible therewith. Consequently, the telecommunica- 
tions system owner is dependent exclusively on the system 
manufacturer for the feature set and feature upgrades of the 
system, 

SUMMARY OF THE INVENTION 

This invention is directed to solving these and other 
problems and disadvantages of the prior art Generally 
according to the invention, there is provided a telecommu- 
nications system infrastructure that facilitates easy insertion 
of feature software into an existing said tdecommuni cations 
system, and easy integration of the new calling features and 
their implementing software with existing features and their 
software. 

Specifically according to one aspect of the invention, a 
call-control apparatus that executes feature-implementing 
software, wherein each call feature is implemented as a 
server program and a cooperating client program, has the 
following elements. An arrangement (illustratively a context 
service) for registering for a user an instance (illustratively 
a user policy) of a server program that implements any call 
feature, in a same manner as any other instances of any 
server programs that implement any call features, substan- 
tially at any time during operation of the call-control appa- 
ratus to provide the call feature for the user. In other words, 
the registration mechanism is identical for all feature- 
implementing programs, and operates dyna m ically. An 
administration interface (illustratively an application pro- 
gram interface, or API) for communicating information 
between the server program and a cooperating said client 
program used by the user, in a same manner as between any 
other client programs and any server programs that imple- 
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ment any call features, to customize the instance of the 
server program for the user. In other words, the administra- 
tion interface is identical for all feature-implementing pro- 
grams. An arrangement (illustratively a context, which is a 

s cyberspace meeting room, along with the context service) 
for involving the instance of the server program in a call to 
which the user is a party, in a same manner as any other 
instance of any server programs that implement any call 
features, to provide the feature to the call. In other words, the 
mechanism for involving feature-implementing programs in 

10 calls is also identical for all features. 

The above-characterized call-control apparatus provides 
all the interaction that is needed between feature- 
implementing programs as well as between feature- 
implementing programs and other service-implementing 

13 programs. Consequently, substantially any feature- 
implementing program that complies with the registration 
and conforms with the administration and in- call- 
involvement communications schemes may be added to and 
used in the apparatus; the call-control apparatus automati- 

20 cally effects integration of any such new feature- 
implementing program into the existing environment. 

Preferably, interactions between feature-implementing 
programs are managed efficiently by having priorities asso- 
ciated with the individual programs. Each instance of each 

25 server program has a priority associated therewith, and the 
arrangement for involving feature-implementing programs 
in calls includes an arrangement (illustratively a context 
service and its context API) that responds to occurrence of 
a request for service (referred to herein as "an event**) in the 

3Q call by giving instances of server programs that are involved 
in the call each a chance to respond to the event in an order 
of their associated priorities. In other words, higher-priority 
programs are given an opportunity to approve or reject 
events before lower-priority programs. The system designer, 
administrator, or users are allowed to change the relative 

35 priorities of the feature-implementing programs and thereby 
control how features interact with each other. For example, 
it allows the administrator to specify whether call coverage 
is invoked for a call before call forwarding, or vice versa. 
Preferably, the arrangement for involving feature- 

40 implementing programs in calls includes a second interface 
(illustratively also an APL referred to herein as the context 
API) for communicating events between a plurality of server 
programs that are involved in the call, in a same manner as 
between server programs that are involved in any other calls. 

45 In other words, the second communications interface is also 
identical for all feature-implementing programs. The 
arrangement responds to receipt through the second inter- 
face of a proposal of an event from a first server program — 
illustratively the originator of the proposed event — that is 

50 involved in a call by sending a request for approval of the 
event through the second interface to the first server program 
and also to other (at least one) second server programs that 
are also involved in the call The arrangement then responds 
to receipt through the second interface of approval of the 

55 event from both the first and the second server programs by 
sending notice of the approval of the event through the 
second interface to both the first and the second server 
programs — and preferably to all server programs that are 
involved in the call — to cause the event to be effected. The 

60 arrangement preferably further responds to receipt through 
the second interface means of rejection of the event from 
either the first or the second server program by forbearing 
from sending an approval of the event to both the first and 
the second server programs to prevent the event from being 

65 effected, and preferably also sends the rejection through the 
second interface to the first server program to abort the 
event 
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Specifically according to another aspect of the invention, be a local-area network (LAN) or a wide-area network 

a method of controlling calls in an apparatus wherein each (WAN). Server 100 and endpoints 101-102 are stcred- 

call feature is implemented as a server program and a program-controlled entities. As such, each includes a 

cooperating client program and which executes the client memory for storing control software, a processor for execut- 

and the server programs, comprises the following steps. In 5 tog the stored control programs, and input and output 

response to a user becoming entitled to a call feature, an interfaces to the outside world, as is well known and 

instance of the server program mat implements the call understood in the art 

feature is registered for the user, in a same manner as any According to well-known software- system design 
other instance of any server programs mat implement any principles, the control software 104 of server 100 and 
call features, substantially at any time during operation of 10 endpoints 101-102 is organized in a multi-layer hierarchy, 
the apparatus, to provide the call feature for the user. Then M me lowcst lcvcl * mc hierarchy, the control 
in response to the user using the client program, information software of server 100 and endpoints 101-102 in this 
is communicated between the server program and the client illustrative example comprises a conventional operating 
program through an administration interface, in a same system 109— such as the Lynx® operating system— that 
manner as information is communicated through the admin- 15 includes conventional device drivers 108. Next in the hier- 
istration interface between any other client programs and ^diy is a conventional networking and transport services 
any server programs that implement any call feature, to lavcr 110 — sucn as the Transmission Control Protocol/ 
customize the instance of the server program for the user. Internet Protocol (TCP/IP)— which provides the 
Then in response to the user becoming a party to a cali the information-movement (i.e., control-signal and information- 
instance of the server program is involved in the call, in a 20 si 8 nal transmission) services between server 100 and end- 
same manner as any other instance of any server programs P° mts 101-102. Built on top of layer 110 is a middleware 
that implement any call features, to provide the feature to the ^yei 111. Middleware is a term for a software platform that 
call. Plug-and-play feature capability is thereby effected for provides network-transparent support for the development 
feature-implementing software. and implementation of network-based distributed-system 
These and other advantages and features of the present * applications (e.g. conmuinications services). It is both an 
invention will become more apparent from the following a^hcaUons-<kvdcpment to^ environment 
a ♦ r mi u a ' It provides a distributed object-based computing infrastruc- 
description of an illustrative embodiment of the invention A r . ... .. ^ . , . _ .., , ° 

taken together with the drawing. ^ "£* u ?"« ^ stribut ° d T^"^" 

6 * network abstraction, and operating-system and transport- 

BRIEF DESCRIPTION OF THE DRAWING 30 Scrv i ce visualization. It therefore allows communications 

applications to be written independently of the resident 

FIG. 1 is a block diagram of an illustrative multimedia operating system, the network transport, the interworking 

communications system; algorithms, etc It also supports a middleware services layer 

FIG. 2 is a block diagram of a call-service model imple- 112 which provides common services that support various 

mented by the system of FIG. 1; 35 communications applications, such as services for session 

FIG. 3 is a block diagram of a call-feature model imple- managem e nt, routing, event collection, service location, etc. 

mented by the system of FIG. 1, which embodies an ilius- Implemented on top of layers Ul and 112 arc appUcations 

trative implementation of the invention; e *S** specific communications services programs. 

FIGS. 4 and 5 are functional flow diagrams of registration AppUcations 113 conimunicate with layers 111 and 112 by 

procedures of feature managers and theif user policies of the « ^f^^npro^mcdaccs (APIs) of layers 111 

odel f FTr 3* * communicate with users and/or administrators 

mooet 01 rt*j. a; ^ intcrfaccs ^fo^ by an interfaces layer 114. In the case 

FIG. 6 is a functional flow diagram of a feature admin- of endpoints 101-1(2, appUcations 113 illustratively com- 

istration procedure of a feature administration agent of the prisc a vcrs i on 0 f insofVs Communique!™ collaboration 

model of FIG. 3; 45 software. 

FIG. 7 is a functional flow diagram of an event- Layers 111 and 112 illustratively comprise the cammu- 

negotiation procedure of a context and context members of nications middleware software of the Lucent Technologies 

the model of FIG. 3; and Inc. MMOC heretofore known as CoMMware. Layer 111 

FIG. 8 is a functional flow diagram of a message-passing comprises the middleware platform, while layer 112 corn- 
procedure of the context of the model of FIG. 3. so prises imddleware<ornpliant service components that make 

use of the middleware platform primitives lo control calls 

DETAILED DESCRIPTION and their different-media components and to supply calling 

FIG. 1 shows one possible architecture of a mniHmrHia features (like call-coverage and call-forwarding, for 

communications system. The system comprises a plurality example.) The service components include service managers 

of communications endpoints 101-102 connected by com- 55 (servers) and service agents (clients), 

munications links 103 with a communications server 100. The middleware platform provides an infrastructure for 

The system of FIG. 1 can be, for example, a telephone bringing parties and multimedia services into communica- 

system where server 100 comprises a multimedia-enabled tions "contexts" which provide bases for negotiation of 

switching system such as a Lucent Technologies Definity® scrvice parameters. Each communications session (e.g., a 

G3 PBX. endpoints 101-102 comprise video workstations 60 multimedia call) is represented by its own context The 

such as the NCR Vistium® stations, and links 103 comprise architecture provides support for customizable service nego- 

high-bandwidth telephone lines such as ISDN BRI lines. tiation and control software, called "policies"* that allows 

However, in this illustrative example, server 100 is assumed application and scrvice developers to meet a wide variety of 

to be a multimedia-services server such as the Lucent product-and service-specific needs. 

Technologies Inc. MMCX multimedia communications 65 In the model of communications that is presented by the 

exchange, endpoints 101-102 are assumed to be multimedia middleware, all communications take place within a context, 

(including video) workstations, and links 103 are assumed to and parties and services are associated with one another as 
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members within the context by a context service. The into a context A brokering service uses the generic nego- 
context service is somewhat analogous to Microsoft Corpo- tiation mechanism provided by the middleware to gather the 
ration's Windows™ system. Just as the Windows system service-related attributes of the parties in the context, 
distributes events that reflect a change in the applications* enabling it to bring other service managers 210-211 into the 
presentation environment to all applications running in that 5 context that can meet their, perhaps diverse, needs. And 
environment, so does the context service distribute events finally, the middleware supports the development of implicit 
which reflect a change in the communications context to all broken which, as policies of context server 201, can exam- 
members of that context In addition to the event-notification ine the attributes of the context and its members to bring 
mechanism, the context service also supports message- services into the context This sort of broker might be used, 
passing among context members, for example, to enable 10 for example, to bring billing services into the context. These 
negotiation of interworking parameters between endpoints brokering mechanisms can also be used in unison. A spe- 
and servers with possibly-disparate capabilities. cialized broker may, for example, gather parties* attributes 
The middleware effectively provides a signaling overlay and formulate a complex query to trading service 124 to 
on top of the underlying network architecture, which overlay locate the right service. 

supports multiparty, end-to-end negotiation that facilitates 15 The middleware provides a framework for introducing a 
the design of interoperable multimedia communications level of signalling and control for communications sessions 
products and services. Middleware concepts of context that fits logically above the transport network. This means 
virtual transport and trading aid in the provisioning of mat software can be written to formalize communications 
multiparty, multimedia distributed communications in net- that are required to set up calls. The middleware supports 
erogeneous environments. 20 codification of the signalling used for service composition 
The model of communications that is presented by the and separates it from that used for control of bearer channels 
middleware is shown in FIG. 2. The middleware facilitates and network connections. A member context agent 203-206 
bringing parties and services together in a "cyberplace*\ of context agent facility 202 utilizes virtual transport to 
which is referred to as context 200. A context server 201 access underlying transport services for establishing a sig- 
manages context 200 to/from which may be added/dropped 2 5 connection to a context server 201, which, in turn, is 
the context members. Members may be parties and services. then able to establish signalling connections with other 
A logged-in user of an endpoint 101-102 who is a member member context agents 203-206. Context agent faculty 202 
of a context is referred to as a party (220-221) to that utilizes a transaction protocol with context server 201 to 
context. A service is represented in a context 200 by its create a context 200 for a communications session and to 
service manager 210-211. Parties and services are treated 30 associate parties 220-221 and service managers 210-211 
identically by context server 201, and are referred to simply with the context Integral to this transaction protocol, the 
as "members**. All members in a context 200 are represented middleware provides a foundation for negotiation among 
by a context agent facility 202. Each member of context 200 parties* service agents 230-233 and service managers 
islc^caUyrer^sentedincOTtextagentfaciu^202byite 210-211 which allows media-specific service agents 
own corresponding member context agent 203-206 (e.g., its 35 230-233 and service managers 210-211 to agree on service- 
own virtual port on context agent facility 202). When specific parameters regarding the communications session, 
context 200 changes as a result of members being added to The specific negotiation protocol as defined in common for 
or dropped from the context, context server 201 alerts all a specific media service, is implemented in replaceable 
members ' context agents 203-206, which in turn notify their program entities (policies) which are bound to context 
corresponding members. When a new member joins an 40 transaction processing. 

existing context 200, all members already in the context are While the communications model supports familiar com- 

similarly notified, and each has a chance to exchange some munication system features (with parties and transport). 

in j j rial "get acquainted** messages with the new member and more elaborate communications in which multiple parties 

with other members that were already in the context In and a rich array of services are added and removed dynami- 

middleware, this is called "negotiation**, since it is generally 45 cally are also supported naturally within the model. For 

used to achieve a common ground for communications example, a two-party voice call can be turned into a multi- 

between the members (parties and services) in the context party conference with a video and a multipoint shared 

The middleware provides support for brokering in three application by adding additional parties, a video-connection 

ways. First the middleware includes trading service 124, service, and a shared-data service to the context Further, 

which is a database system that can be used to locate 50 since the services in a context may be independent of one 

services based on service characteristics. Services are con- another, each can be added and removed at any time without 

stnicted in a client/server configuration, with programs that affecting the others. These attributes of the model result 

actually provide the services, called service managers from the concept of context and the fact that the signalling 

210-211 (also call services, service components, resource or for bearer-channel connection-control and for establishment 

media servers, or resource or media managers), being 55 and control of the context are separate, 

located in MMCX server 100, and programs that obtain the A second example illustrates additional attributes of this 

services from service managers 210-211 on behalf of appli- model If an interactive service (such as "800** -number 

cations in endpoints 101-102, called service agents 230-233 video-catalog shopping) were desired, an endpoint would be 

(also called service clients, or resource or media agents), able to request the service and negotiate the attributes of the 

being located in endpoints 101-102. Service managers 60 service to conform to its own capabilities. But then, the 
210-211 can register with trading service 124, giving their service itself could request that required ancillary services 

service attributes and capabilities. Trading service 124 pro- be added to the context such as billing, order processing, 
vides a query capability to enable service agents 230-233 to and credit card authorization. This illustrates the rundamen- 

obtain identities of services (i.e., of service managers tal symmetry of the middleware architecture that provides 
210-211) that can meet the common needs of the parties in 65 parties and services with the same status in a context, thus 
a context Secondly, specialized brokering services 132 can allowing all members the full power of the context transac- 
be written, which are servers themselves that can be brought tion protocol. 
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As shown in FIG. 1, the middleware is constructed as entity in the middleware is given a virtual transport 
follows. There are six architectural elements to the middle- address (VTA) which allows addressing of and connect- 
ware platform: ing to that entity in a network-independent manner. 
Context service 120: The context service provides the sup- In addition to these elemental services, the middleware 
porting mechanisms for the middleware model of com- 5 provides a programming framework and associated libraries 
nuinications that provides a context for a communications to facilitate development of run-time libraries that imple- 
session in which service providers and service users are ment protocols for middleware -compliant service access and 
treated as undifferentiated members with equal privileges control 130 and brokering services 132. The program enti- 
and capabilities. Context service 120 is provided by ties that are developed within this framework are objects (in 
interactions between a context server 201 that manages a 10 the object-oriented programming sense), called policy mod- 
context 200 and a context agent 202 that represents the ules or policies, that implement service and access control 
members of the context. Communications with context 130 and brokering services 132, and constitute the client/ 
service 120 are effected through a context API 121. server software that provides services and service access. In 
Context API 121 is available to both applications software other words, service managers 210-211 and service agents 
and service modules. This means that, although policy is 230-233 are policies that perform the service- specific nego- 
modules wilt normally buffer applications from context tiation and control functions that are required for service 
transactions, negotiation, and service control it is pos- delivery. 

sible for applications to directly react to and influence To control independently a dynamic mixture of services, 

these activities. the concept of context provides a place to instantiate a locus 

Naming service 122: A distributed naming database that 20 of control for the composition of these services and facili- 
allows the middleware and middleware-based applica- tales the multi-way negotiation needed to deliver the sec- 
tions to access transport addresses associated with a vices to a variety of endpoints. This requires that the detailed 
middleware identifier (CWID). Each service manager attributes of various media services (feature control 
210-211 and party 220-221 has its own CWID. The mechanisms, encoding choices, transport requirements, 
naming service performs two mappings: 1) a mapping 25 delay and synchronization characteristics, etc*) be under- 
from a CWID to a transport-independent address (a stood and agreed-to by service providers (service managers 
virtual transport address, or VTA), and (2) a mapping 110-112) and service users (parties 220-221). 
from a VTA to transport-dependent addresses and The middleware introduces the idea of "negotiation* 1 
attributes. The attributes associated with each VTA Olus- among members, typically between parties and service 
tratively consist of "attribute name; attribute value" pairs, 30 managers, to allow services to be provided in a manner that 
where mere is a fixed set of attribute names supported. ensures compatibility and consistency of service delivery to 
Service agents 230-233 use the first mapping to get the the parties. The middleware provides a framework for 
VTA for a given party or service manager and then give incorporating policy modules into a system that are available 
the resulting VTA to virtual transport service 126, which for use by applications for perforrning service-specific nego- 
calls on naming service 122 to perform the second map- 35 tiation in reaction to changes to the context. Policy modules 
ping in order to obtain actual transport addresses for can also be used during service delivery to provide service- 
establishing transport connections to these parties and control functions, eg., to tell a video server which video 
service managers. Communications with naming service stream to send. Policy modules are essentially service- 
122 are effected through a naming API 123. specific run-time libraries that implement service-specific 

Trading service 124: Trading in the middleware is service 40 negotiation and control protocols. Communications by 

selection based on combined attributes of the members of applications 113 with policy modules of service access and 

a context Trading service 124 is a database that supports control 130 are effected through a service control API 131. 

service registration and the ability to locate service man- Context service 120 with appropriate policy modules 

agers 210-211 by required attributes. Trading service 124 enables deployment of new multimedia services without 

has the ability to satisfy queries from service agents 45 having to enhance underlying network equipment. Naming 

230-233 that require it to find the "best match" of party service 122 and trading service 124 also facilitate service 

attributes to service attributes. Service managers register composition by enabling applications to locate the services 

with me trading database. Brokers can be developed in the that are needed to meet the needs of the members in a 

middleware that use trading service 124 to find a best context Brokering services 132 can be created that perform 

match for the collective needs of the members of a 50 the function of garnering up appropriate party attributes, 

context Communications with trading service 124 are formulating the required trader query, and inviting the 

effected through a trading API 125. returned service manager into the context These brokers 

Remote object management (ROM) service 127: The ROM generally are service-type specific (eg., audio, video, shared 
service is a simple object request broker (in the object- application), and are implemented as separate services that 
oriented programming sense). It uses virtual transport 55 can be added to a context Broker agents work with the 
service 126 to allow object methods to be invoked brokering server to locate the needed service manager and 
remotely. ROM service 127 is available to both the add it to the context In some cases, a broker may be 
middleware itself and to applications and policy modules. implemented as a policy module of context server 201 
Policy modules may make use of ROM service 127 to which, by virtue of its ability to eavesdrop on all context 
establish out-of-context communications channels with 60 transactions, can perform a service-location function. Nam- 
peer or server policy modules. Applications make use of ing service 122 complements the brokering service by 
ROM service 127 to establish client-server connections. providing a facility for converting a middleware entity name 

Virtual transport service 126: An abstraction of transport that to the transport network attributes required to connect to that 

presents a common model for a variety of communica- entity. 

tions networks. The use of virtual transport enhances the 65 Naming service 122 serves both applications 113 and 

portability of applications and services and their interop- virtual transport service 126. Applications typically use 

erability in heterogeneous network environments. Each naming service 122 to map a qualified CWID (e.g., an 
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E.164-confannant address, such as a phone number) into a In order to make context service 120 aware of their 

virtual transport address (VTA, e.g., also an E.164- existence, the user policies of feature managers 300. 35© 

conformant address). The VTA appended with a logical-port must register with context service 120. The registration 

identifier is "handed" to virtual transport service 126 which procedure is shown in FIGS. 4 and 5. Upon its own creation 

uses naming service 122. once again, to map the qualified 5 by an administrator of MMCX server 1*0, at step 401 of 

VTA to transport-specific attributes. For example, say that a FIG. 4, or upon initialization of MMCX server MJO 

user has a CWBD of 303.538.4071, then naming service 122 (whichever is earlier), at step 400, a feature manager 300. 

would be used by a context server 201 to map 350 registers separately each of its user policies M™ 2 - 

303 538 4071.context_port to the VTA of that user's mem- 351-352 with context service 120 of MMCX server 100. at 

ber context agent, which might be 303.538.4000. When the 10 step 402. As part of each registration with context service 

context server 201 wishes to establish a connection to the 120, a feature manager 300. 350 specifies the priority that 

context agent's port for accepting context messages, it asks has been administered for each user policy. The priorities for 

virtual transport service 126 to establish a connection to all user policies of a feature manager may be all the same. 

303.538.4000.context_4>ort. Virtual transport service 126 or they may be different When the priority of one or more 

would, in turn, use naming service 122 to map 15 of its user policies is administratively changed, the feature 

303 538.4000.context_port to the transport specific address manager re-registers with context service 120 with the new 

(es) of the appropriate virtual port on context agent 202. priorities. A feature manager 300. 350 also registers once 

This description of the middleware applies fundamentally with trading service 124 of MMCX server 100, at step 404, 

to both MMCX server 100 and endpoints 101-102, although before concluding registration, at step 406. 

APIs 121, 123, and 125 are the only portions of services 120, 20 Subsequently, at any time whenever a new user is admin- 

122. and 124 that are used on endpoints 101-102. A dis- istered for features or an existing user is administered for a 

tributed client/server architecture is utilized whereby client new feature, at step 410 of FIG. 5, each feature manager 300, 

software (service agents 230-233) in an endpoint 101-102 350 of the user's new features registers the user's new user 

works cooperatively with server software (service managers policies 301-302. 351-352 with context service 120 of 

210-211) in server 100 to provide the brokering services as 25 MMCX server, at step 412. As part of the user policies 

well as the media-control services which provide the value- registration with context service 120, each feature manager 

added communications services to users. 300, 350 specifies the priority that has been administered for 

According to the invention, the above-described infra- the new user policy. Registration of the new user policies 

structure and call model are used to provide support for then concludes, at step 414. 

nlue-and-olay call features in the manner illustrated in FIG. 30 FIG. 6 shows the feature-administration procedure for 

3' feature admin, agents 303-304, 353-354. When a party 220. 

Feature software is implemented using the client/server 221 logs into an endpoint 101, 102, at step 500, each 
architecture. As shown in FIG. 3, each feature comprises a feature's feature admin, agent of the logged-into endpoint 
feature manager (a server module) 300, 350 on MMCX uses trading service 124 to find the identity of the corre- 
server 100 and a plurality of feature administration (admin.) 35 sponding feature manager 300, 350 for the corresponding 
agents (client modules) 303-304, 353-354, one on each feature, at step 502. The feature admin, agent then uses the 
endpoint 101-102. Each feature manager 300, 350 is imple- identity to establish a communications connection with the 
mented as one or more user policies 301-302. 351-352, one corresponding feature manager via administration API 360. 
for each user 220-221 that is entitled to use the feature. Each at step 504, and determines from the feature manager 
user policy 301-302, 351-352 is one user's customized 40 whether there is a corresponding user policy for the logged- 
instance of the feature manager 300, 350, respectively, in party 220, 221, at step 506. If there is not a user's policy 
Feature managers 300, 350 and their user policies that are for the logged-in party, the logged-in party is not authorized 
involved in a call are not members of that call's context 200, to use the corresponding feature, and so the feature admin, 
but each communicates with context 200 through the party agent ends feature administration, at step 510. If a corre- 
context agent 203, 204 of its cc*resrx»ding party 201.202. 45 sponding user policy is found and its identifier is returned by 
User policies of the same and of different feature managers feature manager 300, 350 to the feature admin, agent, the 
300, 350 keep track of each other through the event- logged-in party is authorized to use the corresponding 
notification mechanisms provided by context service 120, feature, and so the feature admin, agent and the party's user 
but they generally do not communicate with each other policy then administer the feature for the party by exchang- 
directly through an out-of-context exchange of messages. 50 ing that party's 'terminal translations" data (as that term is 

Unlike the feature managers, feature admin, agents commonly used in the telephony art), at step 508, before 

303-304, 355-354 are not implemented as policies. Feature ending admimstration, at step 510. The terminal translations 

admin, agents do not execute features, but rather only turn data that is provided by the party's user policy will have 

features on and off at endpoints 101-102 and commiinicate been pre-adimnistered by an adrninistrator of server 100, 
adniinistrative information between parties 220-221 and 35 while the terminal translations data that is provided by the 

feature managers 300, 350. Feature admin, agents and their feature admin, agent is obtained by feature admin, agent 

corresponding feature managers communicate with each through interaction with the logged-in party through the 

other outside of context 200 through an administration API feature's corresponding one of the interfaces 114 on the 

360 that is implemented at the applications layer 113. endpoint. 

Administration API 360 uses trading AH 125 and ROM 60 Consider, for example, the administration for the call- 
service 127 to locate, and to communicate with, feature forwarding feature. The call-forwarding user interface on the 
managers 300, 350. Graphical user interfaces 114 and fea- endpoint invokes the feature adrninistration API 360, pass- 
ture admin, agents for any number of features can be added ing it the call-forwarding feature identifier, the identifier of 
to (or deleted from) any endpoint 101-102 at any time, and the user who is administering call-f orwarding, and a coUec- 
administration API 360 enables the interfaces and agents to 65 tion of call-forwarding administration data, including the 
locate, and to communicate with, the corresponding feature identifier of the forwarded-to party and whether call- 
maoagers. forwarding should become enabled or disabled. The feature 
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administration API 360 queries trading service 124 for the between clients and servers through APIs such as adminis- 

identifier of the feature server that matches the call- tration API 360, for example. Their handling by APIs is 

forwarding feature identifier. Le., the call-forwarding feature shown in FIG. 8. Upon receiving an information message, at 

server. If trading service 124 successfully returns this step 700, an API determines the message's destination, at 

identifier, the administration API 360 sends the call- s step 702, and forwards the message to that destination, at 

forwarding feature server the user's identifier and the call- step 704, before ending, at step 706. 

forwarding administration data. The call-forwarding feature To provide the above-described communications 

server receives the data and stores it in its feature translation capabilities, the various APIs include the following mes- 

database. Henceforth, during call processing, the adminis- sages. 

tration data can be retrieved from the feature translation 10 To allow an administrator of MMCX system 100 and 

database and used to effect the call-forwarding feature. parties 220-221 at endpoints 101-102 to administer the 

For purposes of event-negotiation, event context 200 features, administration API 360 provides a message that 

provides for three types of inter-member communications: comprises one function (command) and three arguments, 

proposals from initiators of events to context event requests The function is "administration request**. The arguments are 

for approval from context to interested policies (those 15 the identifier of the feature that is to be administered, the 

affected by the event), and event notifications from context identifier of the party for which the administration is being 

to all context members. Any proposed event that causes a done, and the administration data for use by the message 

change in context or a change of state of a context member recipient 

must be approved by the policies of the acting context To enable feature managers and service managers to 

member and the policies of the members being acted on. For 20 register with context service 120, context API 121 provides 

example, a request to create a context is an event that must a message that comprises one function and four arguments, 

be approved by all policies of the requestor; a request to add The function is "policy registration request**. The arguments 

or delete a member to or from a context or to change a are the identifier of the feature or service, the user policy that 

member* s state is an event that must be approved by all is registering (the registrant), the name of the party repre- 

policies of the requestor and the subject of the request; and 25 sented by the registrant, and the registrant's priority, 

a request to destroy a context is an event that must be To enable feature managers and service managers to 

approved by all policies of the requestor. register with trading service 124, trading API 125 provides 

FIG. 7 shows me event-negotiation procedure. When an a message that comprises one function and two arguments, 

event proposal is received by context 200 from a policy, at The function is "manager registration request". The argu- 

step 600. context 200 determines from the event which 30 ments are the identifier of the feature or service that is 

context members need to approve the event, at step 602, and registering, and the CWID of the registrant 

then sends event requests for approval to the policies of each To enable feature admin, agents and server agents to find 

member which needs to approve the event — first to the suitable user policies and service managers via trading 

requestor's policies serially and sequentially in the order of service 124, trading API 125 provides two messages. One 

the policies* priorities, and then to the policies of the subject 35 message has a function of "server request** from the agent to 

or subjects of the request serially and sequentially in the trading service 124, and arguments of feature or service ID 

order of the policies* priorities. Context 200 first sends an and feature or service parameters being requested by the 

event-approval request to the highest-priority policy of the agent The other message has a function of "server response** 

event-originator, at step 604. Upon receipt of an event from trading service 124 to the agent, and an argument of 

request for approval, at step 630, each policy that is asked 40 CWID of the feature's user policy or the service manager 

for approval of the event executes whatever algorithm it has selected by trading service 124. 

been programmed with to determine its approval or To enable policies to initiate events, context API 121 

rejection, at step 632, and sends its reply to context 200, at provides a message that comprises any one of six functions 

step 634, before concluding, at step 636. Context receives and four arguments. The functions are "create context**, 

the policy's reply, at step 606, and checks whether it is an 45 "destroy context**, "add member**, "drop member", "change 

approval or a disapproval at step 608. If any policy of any state", and "send message". The arguments are the CWID of 

member who needs to approve the event replies with a the initiator, the new state in the case of the "change state** 

rejection of the event, as determined at step 608, context 200 function, the CWID of the event subject for the functions 

notifies the policy that made the event proposal, at step 621, other than "create context** and "destroy context**, and the 

then ends, at step 622, and the event is not effected If the 30 reason for the event. 

received reply is an approval, context checks whether it has To enable event requests for approval to be made, context 

sent an event-approval request to each policy of the event API 121 provides a message that comprises one function and 

originator, at step 610. If not context 200 returns to step 604 four arguments. The function is "request for approval**. The 

to send the event-approval request to the next-highest pri- arguments are the function and arguments of the event- 

ority policy of the event originator. If all policies of the event 55 initiating message. 

originator have been sent event-approval requests, context To enable event approvals and denials, and notification of 

200 proceeds to steps 612-618 to repeat the procedure of denials to event originators, context API 121 provides a 

steps 604-618 for each policy of the event subjects. If all message that has one function and one argument The 

policies of all context members who need to approve the function is "approval reply**. The argument is either 

event reply with an acceptance of the event as determined 60 approval or a failure code, 

at step 618. context 200 broadcasts notification of the event To enable event notifications, context API 121 provides a 

to all policies of all members of the context at step 620, so message that comprises one function and four arguments, 

mat the policies can implement or take note of, the event The function is "event notification**. The arguments are the 

and ends, at step 622. The event notifications at step 620 are function and arguments of the event-initiating message, 

not prioritized. 65 To enable in-context communication among context 

The policy priorities do not affect information messages, members, context API 121 provides a message that has one 

which are data messages or requests for information sent function and four arguments. The function is "send mes- 
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sage**. The arguments are the CWID of the destination party, 
the ID of the feature or service being communicated with, 
the ID of the user policy being communicated with, and the 
message data. If the policy ID is omitted, the message is sent 
to all user policies of the identified feature or service. 5 

To allow information-passing between user policies and 
feature admin, agents, administration API 360 provides a 
message that comprises one function and one argument The 
function is "administer". The argument is an arbitrary data 
field. 10 

Given this infrastructure, almost anyone can create a 
feature (that is. feature software) for use therein. Substan- 
tially the only requirements placed on the feature software 
are that (a) it have a client/server construction, that is, be 
constructed as a feature-manager server module plus a 15 
feature admin, agent client module and (b) be compliant 
with messages of the interfaces (context API 121, adminis- 
tration API 360, and trading API 125 in this example) that 
were enumerated above, and with their functions. Compli- 
ance with requirements (a) and (b) above ensures that the ^ 
feature can both operate in the system of FIG. 1 and 
inter-operate with other features and services of the system 
of FIG. 1. In other respects, the internal structure and 
functionality of the feature are irrelevant to the system of 
FIG. 1 and its various components, both hardware and ^ 
software. 

Of course, various changes and modifications to the 
illustrative embodiment described above will be apparent to 
those skilled in the art. For example the context service need 
not be provided by a single server, but may be distributed ^ 
across a network of servers. Also, the industry-standard 
Object Management Group's (OMG's) object request bro- 
ker (ORB) could be used instead of the remote object 
management (ROM) services and the virtual transport (VT) 
services. Furthermore, the middleware and its functions 35 
could be distributed over a plurality of servers. Also, addi- 
tional functions and messages may be added to the APIs. Or 
in addition to, or instead of, the context API protocol, the 
system can support other multimedia communication pro- 
tocols (e.g., enhanced H.323, H320, T.120, conventional ^ 
audio telephony protocols). Such changes and modifications 
can be made without departing from the spirit and the scope 
of the invention and without diminishing its attendant 
advantages. It is therefore intended that such changes and 
modifications be covered by the following claims. 4S 

The invention claimed is: 

1. A call-control apparatus wherein each call feature is 
implemented as a server program and a cooperating client 
program, comprising: 

means for executing the client and the server programs; 50 

means for registering for a user an instance of a server 
program that implements any call feature, in a same 
manner as any other instances of any server programs 
that implement any call features, substantially at any 
time during operation of the call-control apparatus to 33 
provide the call feature for the user; 

an administration interface for communicating 
information, between the server program and a coop- 
erating said client program used by the user, in a same 
manner as between any other client programs and any 60 
server programs that implement any call features, to 
customize the instance of the server program for the 
user; and 

means for involving the instance of the server program in 
a call to which the user is a party, in a same manner as 65 
any other instance of any server programs that imple- 
ment any call features, to provide the feature to the call. 



14 

2. The apparatus of claim 1 wherein: 

each instance of each server program has a priority 
associated therewith; and 

the means for involving comprise 

means responsive to occurrence of an event in the call, for 
giving instances of server programs that are involved in 
the call each a chance to respond to the event in an 
order of their associated priorities, to control interac- 
tion between the features implemented by the instances 
of the server programs that are involved in the call. 

3. The apparatus of claim 1 wherein 
the means for involving comprise: 

a second interface for communicating events between a 
plurality of server programs that are involved in the 
call, in a same manner as between server programs that 
are involved in any other calls; 

means cooperative with the second interface, responsive 
to receipt through the second interface of a proposal of 
an event from a first server program that is involved in 
the call, for sending a request for approval of the event 
through the second interface to the first server program 
and to a second server program that is also involved in 
the call; 

means cooperative with the second interface and respon- 
sive to receipt through the second interface of approval 
of the event from both the first and the second server 
program, for sending the approval of the event through 
the second interface both to the first server program and 
to the second server program to cause the event to be 
effected, and responsive to receipt through the second 
interface of rejection of the event from either the first 
or the second server program, for forbearing from 
sending the approval of the event both to the first server 
program and to the second server program to prevent 
the event from being effected. 

4. The apparatus of claim 3 wherein: 

each server program has a priority associated therewith, 
and 

the means for sending a request for approval are respon- 
sive to the receipt of the event, for sending the request 
for approval to the first and the second server programs 
serially in an order of the priorities of the first and the 
second server programs, to control interaction between 
the features implemented by the first and the second 
server programs. 

5. The apparatus of claim 4 further comprising: 
means for administratively changing the priorities that are 

associated with server programs, to change the inter- 
action between the features implemented by the server 
programs. 

6. The apparatus of claim 1 wherein: 

the administration interface communicates information 
between the server program and the cooperating client 
program used by the user to customize a registered said 
instance of the server program for the user; and 

the involving means involve a customized registered said 
instance of the server program in the call to which the 
user is a party. 

7. The apparatus of claim 1 wherein: 

each feature's server program comprises a plurality of 
instances of the server program, one for each user who 
is entitled to the feature. 

8. The apparatus of claim 1 wherein: 
the executing means comprise 

means for executing the server programs, and 
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at least one means for executing the client programs; 
the server programs, the means for executing the server 

programs, the registering means, and the involving 

means are included in a call controller; 
an instance of the client program of each of at least some 5 

of the features and one of said means for executing the 

client programs are included in each of at least one call 

endpoint; and 

the administration interface interfaces the at least one call 1Q 
endpoint with the call controller to communicate infor- 
mation between server programs on (he call controller 
and the instances of the client programs on the at least 
one endpoint. 

9. A method of controlling calls in an apparatus wherein 15 
each call feature is implemented as a server program and a 
cooperating client program and which executes the client 
and the server programs, comprising the steps of: 
in response to a user becoming entitled to a call feature, 
registering for the user an instance of the server pro- 20 
gram that implements the call feature, in a same manner 
as any other instance of any server programs that 
implement any call features, substantially at any time 
during operation of the apparatus, to provide the call 
feature for the user; 
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in response to the user using the client program, commu- 
nicating information between the server program and 
the client program through an administration interface, 
in a same manner as information is communicated 
through the administration interface between any other 
client programs and any server programs that imple- 
ment any call feature, to customize the instance of the 
server program for the user; and 

in response to the user becoming a party to a call, 
involving the instance of the server program in the call, 
in a same manner as any other instance of any server 
programs that implement any call features, to provide 
the feature to the call. 

10. The method of claim 9 wherein: 

each instance of each server program has a priority 
associated therewith; and 

the step of involving comprises the step of 

in response to occurrence of an event in the call, giving 
instances of server programs that are involved in the 
call each a chance to respond to the event in an order 
of their associated priorities, to control interaction 
between the features implemented by the instances of 
the server programs that are involved in the call. 

***** 
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